The present invention relates to data processing methods, systems, and computer program products, and, more particularly, to data processing methods, systems, and computer program products for managing email in a client-server environment.
Electronic client devices, such as personal digital assistants, cellular phones, and the like, may be used to receive, send, and generally manage emails. Such devices are often used in conjunction with a host server device where the user's email may also be stored. As a result, a synchronization server may be used to synchronize the email stored on the client device with the email stored on the host server device. Unfortunately, client devices may have limited memory space, which may result in the need to truncate various email fields, such as the “To,” “CC,” and/or “BCC” lists. Because data integrity and the prevention of data loss are goals of synchronization, however, reconstruction of truncated fields is a part of the server-client synchronization interaction. Because the client devices may have finite, strict, and/or unchangeable limitations as to the amount of information that can be stored in their fields, methods for truncation may be used for one or more fields in a manner that allows for lossless reconstruction.
One approach to truncation of email fields involves the use of Globally Unique IDentifiers (GUIDs) by the synchronization server and the client device. The synchronization server controls the truncation process and tracks mapping information between the synchronization server's GUID and the client device's GUID for each individual email. In particular, the synchronization server is able to truncate one or more fields to the necessary size and save information regarding which fields have been truncated on the server during synchronization. If an email item is updated on the client device, then the synchronization server is able to correlate the modified email with the email stored at the host server device using the GUID. The synchronization server may then reject the client device's modification or may use an algorithm to ensure consistency between the version of the email on the client device and the version of the email on the host server device. For this approach to be effective, however, the synchronization server must be able to use the mapping information to retrieve the truncation information. This approach may not be effective when a modification is performed at the client device in such a way that the client uses a different GUID that has no relation to the previous GUID. For example, if the client were to perform a “reply all” to a truncated To/CC/BCC list in an email or a truncated attendee list of a calendar event, then the synchronization server may be unable to resolve the truncation to reconstruct it.
Conventional synchronization servers may address this problem by preventing users from performing such operations. For example, an email's To/CC/BCC list may be completely truncated so that replying is impossible or the email address list may be truncated down to a non-existent address, such as truncated@truncated. Replying to this truncated email address may result in a delivery failure. Such an approach has been justified because, in general, the majority of emails that are responded to are emails with only a few recipients and, therefore, do not need truncation. Also, many emails that do contain numerous recipients are “broadcasted” emails that are typically not conducive to a “reply all” response.
Another conventional solution to this problem is to use a contact group, which is a collection of users that are described by a single name and, therefore, use less space. The synchronization server may take a new email that needs truncation and replace the To/CC/BCC list with a new contact group that has just been created. This may allow the user via the client to reply to all the recipients. This solution may have some drawbacks, however. The solution assumes the atomic synchronization of both email and contacts and, therefore, would not be applicable in an email-only environment. The solution also involves the synchronization server creating contact groups. An end user may find such new contact groups surprising, unexpected, and/or annoying. Moreover, to prevent creating multiple contact groups of the same address list, the synchronization server may need to traverse all of the existing contact groups to parse them for duplicates. Each additional synchronization session may create additional contact groups as more emails are truncated, which may result in a degradation of system performance and end-user satisfaction.